home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 2.7 KB | 55 lines | [TEXT/GEOL] |
- Item 7510013 19-Jan-90 13:08
-
- From: ALGER Alger, Jeff,VCA
-
- To: D4384 US Voting Mach, Sarner, Calvin,PRT
-
- cc: MACAPP.TECH$ MacApp Technical
-
- Sub: Re: Persistent Objects
-
- Greg,
-
- Your scheme is sound as far as it goes. Methods should be dispatched properly
- & etc. I will state the obvious, though: it is up to your program logic to
- make sure that the SwapIn method is called before any attempt to access the
- instance variables. Furthermore, the reference count scheme needs further
- refinement: if a reference count goes to 0, should the object perhaps disappear
- altogether, rather than be flushed to disk? If not, how does one know when to
- use the reference counter and when not to? There are some subtleties here.
-
- As to IsObject failing, there is a sneaky way to get around that, if you are
- willing to hold your nose: change the class ID to that of the superclass
- TFileObject when you flush it to the cache, then change it back when you read
- it back in! As long as the object is at least as large as
- TFileObject.GetClassSize, it will pass muster (no, sadly, overriding
- GetClassSize will not do.) This allows you to shrink an arbitrarily sized
- subclass to the size of a TFileObject. OK, it's not pretty, but it should get
- the job done. It also prevents methods of the subclass from being called while
- the object is out on disk, which is HIGHLY desirable behavior.
-
- This still, as Larry Rosenstein has pointed out, is not a general solution to
- the persistent object problem, since it does not address persistence of methods
- as well as data. That can only be done with support from the compiler and
- linker, which today force all possible methods to be known in advance of
- program execution (thereby ruling out linking new methods at run time.) It
- also does not address - without great exertion by the programmer - the problem
- of knowing when to write out "owned" objects automatically. This is a problem
- which can only be addressed through either compiler assistance or more
- meta-information available at run time.
-
- Another shortcoming is that the number of handles used in memory is not
- reduced, only the amount of memory. If you have large objects, this is not the
- primary concern. My experience, however, has been that the number of handles
- can easily be the larger problem.
-
- This is not intended to be discouraging. Your solution addresses a wide class
- of problems, is innovative, and deserves further study and experimentation.
- Perhaps there are other tricks which can be added on top to address some of
- these remaining problems. Keep plugging!
-
- Jeff Alger
- KPMG Peat Marwick
-
-
-